Fix netconf 1.1 chunk parse #181
Conversation
netixx
force-pushed
the
fix/netconf-chunk-parse
branch
2 times, most recently
from
4b78220
to
ce53aba
Compare
netixx
force-pushed
the
fix/netconf-chunk-parse
branch
from
ce53aba
to
4e3b5bc
Compare
|
ah very nice. I have some fear about this due to the newline shenangengins that it looks like you ran into as well :) will take a closer peak this weekend to test it out! |
|
went through all that to make sure I understood it all! very nice solution @netixx ! I made some minor changes -- mostly just tweaking things so it fit my brain a bit better. only meaningful change it think is that that the max chunk length check. I think we only need to check chunk lengths for up to 10 chars (that giant number from the rfc but the actual char positions in that number) -- so I changed things a bit to only check up to 10 chars. if the let me know if you're ok with these tweaks and then we can get it merged and cut another minor release! |
|
It's all good to me, the way I was calculating the max chunk length was a bit silly indeed :) |
I stumbled upon an issue with the current netconf 1.1 parser.
My payload contained
########characters on a single line, which matched the pattern defined in the regex erroneously.I added a test for it, and proposed a new implementation of the chunk matching mechanism using a basic for loop.
Since the size of the chunk is known in advance, we only need to detect the chunk marker, and consume all data up to the length of the chunk and repeat.
As a bonus, we don't need to do expensive regex on very large payloads, so we should achieve faster speeds and less memory usage.